3.3.2 - Form control labels using non-text content #4626
Conversation
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| the task without undue confusion or navigation. | ||
| </p> | ||
|
|
||
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. |
There was a problem hiding this comment.
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. | |
| <p>Labels of form controls are usually text-based. Images with appropriate text alternatives can serve as labels without additional text. |
|
|
||
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. | ||
| In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.</p> |
There was a problem hiding this comment.
Suggest merging the two sentences just into one?
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. | |
| In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.</p> | |
| <p>Images (with an appropriate text alternative) can serve as descriptive labels without additional text. In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.</p> |
There was a problem hiding this comment.
I prefer to point out "Labels of form controls are usually text-based.".
It makes clear that using labels is the exception, and that we are talking about forms here.
There was a problem hiding this comment.
I still fundamentally disagree that we need to make any kind of "this is common, this is the exception" statement here. That seems to add some sort of judgement on our part that has no business being here. Per the actual definition of label, it's "text or other component with a text alternative". No "but mostly text" or anything else. Adding qualifiers about what's "an exception" seems inappropriate to me.
| </p> | ||
|
|
||
| <p>Labels of form controls are usually text-based. In some cases, images can serve as descriptive labels without additional text. | ||
| In these cases, authors should ensure that the image and its use as a label (in context) are widely understood.</p> |
There was a problem hiding this comment.
I feel like this "widely understood" sentence would probably be better in Headings and Labels. Although it is goes beyond a simple discussion on descriptive text, the qualitative concepts of Headings and Labels seems like a better fit than the basic question of 3.3.2 which is: is there a label for the input?
Some task force members ended up having a long post-meeting discussion on the nuances of the telephone example in the original issue. It would be good to try to capture some of those concepts in our guidance, in some way.
There was a problem hiding this comment.
agree, the qualitative part should be moved to headings and labels (and, at a stretch, then cross-referenced from here)
There was a problem hiding this comment.
@giacomo-petri I suggest that line 44 come out, and use some of this discussion to create a new PR for Heading and Labels.
|
After our after-hours chat last Friday, I've put together several codepen examples where the legend, combined with the visual context, should be (IMO) sufficient or where a visible label for each input may not be strictly necessary (though an accessible name is still required): https://codepen.io/giacomo-usablenet/full/vELaXpN We can review them together during our next meeting if you'd like. Note: These examples are only partially functional (if something doesn't work, just ignore it; the goal is to illustrate the concept). |
|
@giacomo-petri thanks for those examples. I just think that's a slightly different use case from an input with no text that could be considered its label. I also think some of your examples do not actually use an image as a label. The "visual content", as you put it, is part of the UIC, not an image serving as a label. So it feels like this is drifting away from the question about an image as a label, which is I thought was the focused of the discussion? I still feel like it is totally valid -- and important -- to say that most labels are text-based. That is the reality. Maybe it's also worth pointing out the historical example still part of the current Understanding document, which somewhat covers some of the considerations in your examples:
|
|
Briefly discussed on Backlog call 10/31. Left in drafted pending incorporation of feedback. |
|
Sorry, I was focusing only on examples where each fieldset has an associated legend, but there are many cases where there's no legend and the input still makes sense on its own. I've put together a bunch of examples here: https://codepen.io/giacomo-usablenet/full/yyeGYLx |
Closes #3808
This PR clarifies the guidance regarding non-text content used as labels for form controls (re-used 2.4.6 wording). For example, in a form field set for phone numbers with country code and number, using a flag as the visual label may be sufficient, provided that a meaningful accessible name is also provided separately in accordance with SC 4.1.2.
This addresses the initial concern, but doesn’t cover the point raised by @amberhinds. It might be worth opening a separate issue, or we could discuss it first and decide on the best way to address it.